1. Field of the Invention
The invention relates to telecommunication technologies, and in particular, to correlating signaling traffic for service sessions in packet service networks.
2. Description of the Prior Art
Packet based telecommunication services have gained wide spread acceptance as packet related technologies have advanced. For example, many service providers now offer packet voice services. An example of a packet voice service is Voice over Internet Protocol (VoIP) service. In addition, service providers offer a variety of other services, such as multi-media downloading, video conferencing, and data services. One problem associated with packet voice services is reliability. Service providers have not been able to provide high quality service with a robust level of reliability. In addition, service providers have been unable to directly measure the quality of any one call.
One solution to this problem is the Real-Time Transport Control Protocol (RTCP). RTCP provides a mechanism whereby call quality metrics for a call are measured and reported to ensure high quality packet voice calls. FIG. 1 illustrates a telecommunication system 100 in the prior art that utilizes RTCP.
Telecommunication system 100 includes access provider network 110, service provider network 120, and public switched telephone network (PSTN) 130. Access provider network 110 includes origination device 111, media gateway controller (MGC) 113, and routing system 114. Service provider network 120 includes routing system 124, gateway 122, and MGC 123. PSTN 130 includes destination device 131. As is well known in the art, user communications for a typical call from origination device 111 to destination 131 are routed through routing systems 114 and 124 to gateway 122. Gateway 122 translates the communications from a packet format understood by service provider network 120 to a circuit switched format used by PSTN 130. Elements within PSTN 130 then route the communications to destination device 131.
FIG. 2 illustrates the operation of RTCP in the prior art with respect to telecommunication system 100. As discussed above, user communications for a call are exchanged between origination device 111 and destination device 131. Communications sent from origination device 111 are addressed to gateway 122. Gateway 122 receives the communications and places them in a format to be routed to destination device 131. Communications from destination device 131 are received by gateway 122 and addressed for origination device 111. A number of well known re-addressing schemes are used to hide the actual address of the elements involved in the call.
During the call, origination device 111 collects call performance statistics on the call. For example, origination device 111 collects packet loss, packet delay, and packet jitter statistics for the call. In accordance with RTCP, origination device processes the call statistics at the end of the call to determine a final performance metric for the quality of the entire call. Similarly, gateway 122 collects the same call statistics for the call. Gateway 122 also processes the statistics to determine a final performance metric based on the call statistics.
At the end of the call, the user at origination device 111 ends the call. An on-hook message is transmitted from origination device 111 to MGC 113. In some cases, MGC 113 transmits a call release message to MGC 123 indicating that the call has ended. MGC 123 then transmits an instruction to gateway 122 to release the call. As illustrated in FIG. 2, origination device 111 transmits its final performance metric in an RTCP message to gateway 122 indicating the quality of the call from the perspective of origination device 111. Similarly, gateway 122 transmits its own final performance metric in an RTCP message to origination device 111.
Unfortunately, upon receiving the RTCP message from gateway 122, origination device 111 drops the RTCP message. This is problematic because the RTCP message from gateway 122 is not stored for later network analysis. Thus, any quality issues that may have arisen during the call can only be solved after the call has ended. Additionally, RTCP messages indicate in a quantitative manner that a call has experienced a quality issue. However, RTCP messages do not indicate why a quality problem has occurred.